home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / admin / bugs / bugs.active < prev    next >
Encoding:
Text File  |  1992-12-02  |  9.2 KB  |  256 lines
  1. Log-Number: 30635
  2. Date: Sat, 19 Jan 91 03:07:17 PST
  3. From: dlong (Dean Long)
  4. Subject: kernel memory leaks
  5.  
  6. I went through most of the filesytem directories, looking for
  7. possible memory leaks, since prolonged disk activity causes
  8. our kernel to eat up all of memory (and crash).  Here is what
  9. I found:
  10.  
  11.     file        line allocated        line lost
  12.  
  13. fs/fsSysCall.c
  14.             71            74
  15.             80            86
  16.             762            765
  17.  
  18. fsconsist/fsconsistCache.c
  19.             2016            2074
  20.  
  21. fsprefix/fsprefixOps.c
  22.             2211            2221
  23.  
  24. "line allocated" is the line number where the memory was allocated,
  25. and "line lost" is line number of the (return) statement that
  26. causes the non-freed memory to be lost, usually because of some
  27. sort of failure.
  28.  
  29. dl
  30.  
  31. [16-Apr-92: JHH volunteered to take care of these. -mdk]
  32.  
  33.  
  34. Log-Number: 31045
  35. Date: Sun, 12 May 91 18:56:32 PDT
  36. From: mendel (Mendel Rosenblum)
  37. Subject: Re: Lfs killed allspice
  38.  
  39. > Allspice died with:
  40. > SCSI #3 DMA bus error
  41. > Lfs error on /sprite/src/kernel status 0x1 bad lfsStable MemBlockHdr
  42. > I took a core: vmcore.lfs
  43.  
  44. The problem here is not in LFS but in the SCSI HBA hardware or driver.
  45. The HBA is aborting the LFS read operation with a DMA bus error 
  46. operation.  This appears to happen when the system is doing much
  47. I/O such as during fscheck the disk.  It appears that LFS can
  48. also trigger the condition.  We need to either fix this or 
  49. put in a patch to retry the operation that gets aborted. 
  50.  
  51.     Mendel
  52.  
  53.  
  54.  
  55. Log-Number: 31086
  56. From: mendel (Mendel Rosenblum)
  57. Subject: Allspice ipServer dies / sendmail problem
  58. Date: Thu, 23 May 91 11:18:14 PDT
  59.  
  60.  
  61. Sendmail on allspice was comatose this morning.  I suspect it went comatose
  62. about the time the following messages appeared in allspice's syslog:
  63.  
  64. <18>May 23 07:51:55 sendmail[40e38]: NOQUEUE: SYSERR: getrequests: accept: invalid argument
  65.  
  66. I did a kill -KILL on the sendmail process and the ipServer on allspice
  67. died. 
  68.  
  69.     Mendel
  70.  
  71.  
  72. Log-Number: 31156
  73. From: mendel (Mendel Rosenblum)
  74. Subject: Deadlock with migration and recovery
  75. Date: Mon, 10 Jun 91 15:22:50 PDT
  76.  
  77. Terrorism was hanging migrations to it because of the following deadlock.
  78.  
  79. Process 0x20 - A pmake from tyranny was being migrated off terrorism. The
  80. call stack looked like:
  81.  
  82. (gdb) where
  83. #0  0xf600c6d0 in Mach_ContextSwitch ()
  84. #1  0xf60ad180 in SyncEventWaitInt (...) (...)
  85. #2  0xf60abe64 in Sync_SlowWait (...) (...)
  86. #3  0xf60bdfb8 in VmPageFreeInt (...) (...)
  87. #4  0xf60be018 in VmPageFree (...) (...)
  88. #5  0xf60bca10 in FreePages (...) (...)
  89. #6  0xf60bbd0c in Vm_EncapState (...) (...)
  90. #7  0xf608bc6c in Proc_MigrateTrap (...) (...)
  91. #8  0xf60ab390 in Sig_Handle (procPtr=(struct Proc_ControlBlock *) 0xf63bb4d0, sigStackPtr=(Sig_Stack *) 0xf63be540, pcPtr=(char **) 0xf805fe3c) (signals.c line 1223)
  92. #9  0xf600ea7c in MachUserAction (...) (...)
  93. #10 0xf6010978 in MachReturnFromTrap ()
  94.  
  95. The routine Proc_MigrateTrap() locks the process table entry for the current
  96. process before calling Vm_EncapState().  The routine VmPageFreeInt()
  97. is waiting for recovery on allspice so it can write out a dirty page
  98. of the data segment.  This wakeup never happens because 
  99. the Proc_ServerProc doing the recovery with allspice has a stack that
  100. looks like:
  101.  
  102. #0  0xf600c6d0 in Mach_ContextSwitch ()
  103. #1  0xf60ad180 in SyncEventWaitInt (event=4131108156, wakeIfSignal=0) (syncLock.c line 655)
  104. #2  0xf60abe64 in Sync_SlowWait (conditionPtr=(struct Sync_Condition *) 0xf63bb53c, lockPtr=(struct Sync_KernelLock *) 0xf6160bd8, wakeIfSignal=0) (syncLock.c line 298)
  105. #3  0xf6095bc0 in Proc_Lock (procPtr=(struct Proc_ControlBlock *) 0xf63bb4d0) (procTable.c line 416)
  106. #4  0xf608f8fc in Proc_WakeupAllProcesses () (procMisc.c line 988)
  107. #5  0xf605c53c in Fsutil_Reopen (...) (...)
  108. #6  0xf609aa30 in RecovRebootCallBacks (data=(ClientData) 0xe) (recovery.c line 1153)
  109. #7  0xf6094e8c in Proc_ServerProc (...) (...)
  110. #8  0xf60a83e8 in Sched_StartKernProc (...) (...)
  111.  
  112. While trying to do a Proc_WakeupAllProcesses(), it hit the locked 
  113. process table entry from the migrate and hung. This left terrorism
  114. hung in recovery with allspice.  I rebooted terrorism.
  115.  
  116.     Mendel
  117.  
  118.  
  119. Log-Number: 31191
  120. From: mendel (Mendel Rosenblum)
  121. Subject: Problem with SparcStation and sun4 running out of PMEGs
  122. Date: Sat, 29 Jun 91 14:54:43 PDT
  123.  
  124. While doing some stress testing of some changes I made to LFS I ran into 
  125. the following problem with the Sprite kernel memory management on the
  126. sparcStation1 and sun4.
  127.  
  128. Remember that the SparcStation MMU has hardware page mapping tables 
  129. called PMEGs that are used to map virtual addresses into physical
  130. addresses.  The way the Sprite kernel is coded it must wire down the
  131. PMEGs used to map the Sprite kernel.  Awhile back I changed the code
  132. not to wire down the PMEGs used to map the kernel's file cache. 
  133. (This was limiting the size of the file caches on the sun4).  On
  134. the SparcStation1, there are 128 PMEGs available.  Each PMEG map
  135. 64 4K pages (256 Kbytes of mapping). 5 of them are allocated to the 
  136. PROM so are unavailable for Sprite.  This leaves 123 PMEGs or around 30
  137. megabytes of mapping available for Sprite, the file cache, and all
  138. user level processes.  The size of the Sprite kernel code and
  139. static data is is around 1428.8 kilobytes which uses 6 PMEGs
  140. to map.  The malloc()'ed data size of the Sprite kernel is around
  141. 5.3 megabytes which requires around 23 PMEGs wired.  Next
  142. comes the kernel stacks. There are 3 megabytes allowed for
  143. kernel stacks. These PMEGs only need to be wired if a process
  144. has allowed a stack on the PMEG.  Since there is no code trying to
  145. allocated kernel stacks on the same PMEGs, it tends to allocate
  146. stacks on most of the PMEGs. This accounts for around 10 wired PMEGs.
  147. Another 5 PMEGS are wired for devices and DMA mapping.  Together this
  148. accounts for close to 50/128 (40%) of the PMEGs.   The rest (78 PMEGs)
  149. are available to user programs and the file cache.  
  150.  
  151. The file cache on a SparcStation with 28 megabytes of memory is allocated
  152. 21 megabytes of virtual addresses. To totally map this would take 87
  153. PMEGs which is more that we have.  Fortunately, the file cache only
  154. wires a PMEG when a cache block is being accessed, read, or, written.
  155. This is typically only a few blocks at a time.  The problem occurs
  156. during a LFS segment write.  Assume a segment size 512*1024. This means that
  157. the write back code may try to write 128 4096-byte blocks at once. If 
  158. the cache blocks are spread out in the cache, it could cause the entire 
  159. file cache to become wired.  This happened on larceny. The segment being 
  160. written contained 132 blocks which happened to reside on 78 different
  161. PMEGs.  Larceny panic'ed because it ran out of PMEGs.
  162.  
  163. Allspice is in slightly better shape because it has 512 pmegs.  With
  164. a kernel image of 32 megabytes wiring 128 pmegs, it has 380 some PMEGs
  165. for the file cache and user processes.   Still, if someone were to
  166. write 1024 files of size less than 512 bytes and these files that happen 
  167. to reside on over 380 different PMEGs and LFS tried to write them all
  168. into the same segment; the same sort of thing that crashed larceny
  169. will happen on allspice.
  170.  
  171.  
  172.     Mendel
  173.  
  174.  
  175. Log-Number: 32734
  176. Date: Tue, 3 Nov 92 17:24:13 PST
  177. From: shirriff (Ken Shirriff)
  178. Subject: Allspice reboot
  179.  
  180. Processes started hanging on allspice.  I took a core; apparently
  181. pseudodevices were hanging up.  The only explanation I can think of is an
  182. ipServer problem.
  183.  
  184. More importantly, when I rebooted with new, allspice couldn't find the
  185. root directory and started broadcasting for "/".  I tried this a couple times
  186. with the same results.  Booting with sprite worked.  Apparently the new
  187. kernel has a serious problem.
  188.  
  189. Ken
  190.  
  191.  
  192. Log-Number: 32735
  193. Date: Tue, 3 Nov 92 23:39:59 PST
  194. From: mgbaker (Mary Gray Baker)
  195. Subject: Re: Allspice reboot
  196.  
  197. Argh.  I will get rid of the new kernel on allspice, so that it is only
  198. possible to boot the old one.  This is particularly annoying, because I
  199. *did* test the new kernel on servers, but of course not on a root server since
  200. there's only allspice for that.  I will try to find what's the problem for
  201. the root server.
  202.  
  203. Sorry for all the trouble,
  204. Mary
  205.  
  206. Log-Number: 32737
  207. From: jhh@sprite.Berkeley.EDU (John H. Hartman)
  208. Date: Wed, 4 Nov 1992 23:32:20 PST
  209. Subject: allspice crashed due to invalid segNum
  210.  
  211.  
  212. Allspice paniced running the 1.115 kernel due to an invalid segNum.
  213. This happened while cleaning /user1 so I was worried that lfs had
  214. a problem again but after greping through the code I discovered
  215. that the message was coming from the vm module. I took a core,
  216. vmcore.invalid.segnum, and rebooted it. This time it cleaned the
  217. disk ok. I'll look at the core tomorrow.
  218.  
  219. John
  220.  
  221. Log-Number: 32741
  222. Date: Sun, 8 Nov 92 17:11:55 PST
  223. From: shirriff (Ken Shirriff)
  224. Subject: ipServer out of control on clove
  225.  
  226. Clove's ip.out file was 61MB long, full of:
  227. Sock_NotifyWaiter: PDEV_READY ioctl: bad argument to a filesystem routine
  228.  
  229. Ken
  230.  
  231. Log-Number: 32742
  232. Date: Mon, 9 Nov 92 09:30:44 PST
  233. From: mottsmth (Jim Mott-Smith)
  234. Subject: Recoverable error on /user5
  235.  
  236.  
  237. Lust reported:
  238.     Target 6 LUN 0 recoverable error
  239.     Info bytes 0x0 0x19 0xd4 0x5e
  240.  
  241. -- Jim M-S
  242.  
  243.  
  244. Log-Number: 32743
  245. From: jhh@sprite.Berkeley.EDU (John H. Hartman)
  246. Date: Mon, 9 Nov 1992 21:56:46 PST
  247. Subject: tar.gnu (dumps) die on /X11/R5
  248.  
  249.  
  250. Tar.gnu dies dumping /X11/R5. I'm skipping this file system so I can
  251. get the full dumps done and restart our daily dumps.  I'll try to figure
  252. out what's wrong and get it dumped as soon as possible, but I don't
  253. think there is much important on there anyway (or much that's changed).
  254.  
  255. John
  256.